\section{Architecture and Implementation}\label{sec:impl}

\begin{itemize}

\item{Central problem: preserving data across failures}
  \begin{enumerate}
  \item{What data are checkpointed?}
  \item{When in exec. and where in program to checkpoint?}
  \item{How to handle transient/temporal data in checkpoints? }
  \item{How to recover?  How to recover in the presence of temporal/transient data?}
  \end{enumerate}


\end{itemize}

\subsection{Operating System Support}

The context for \sys is embedded devices that operate on short bursts of energy.
To maximize the share of the platform's meager resources that are available to
applications, \sys provides \emph{consistent persistence} as the only service
between hardware and applications.

A natural question to ask is why not to provide a more full-featured operating
system, such as one of the existing OSes for sensor motes~\cite{tinyos,
contiki}.  The key challenge in supporting a conventional OS is the sheer amount
of state that an OS carries as it runs.  Driver state in particular poses a
difficult problem, since it is tied to the state of physical devices, and that
state may change between periods of energy availability.

We therefore structure \sys as a thin runtime wrapper around applications.
